1. Field of the Invention
The present invention relates generally to the field of security requirements in software systems and, more particularly, to methods and systems for implementing security requirements into application code.
2. Description of the Related Art
Security evaluations for software systems can be time consuming and expensive endeavors. In particular, the tracing of security requirements into code and the accurate maintenance of that mapping as a system evolves over time can be tedious and error-prone. It has been generally recommended to those who wish to have secure systems that they should integrate the required security functionality into their system designs at the earliest possible stages of the process. However, even when the full complement of security requirements are known in advance, the manner in which security functionality is traditionally integrated, which is via largely manual methods, can cause its own problems. Such problems can make assurance claims more difficult to support and result in systems which are more difficult to understand, evolve, and ultimately to certify and accredit from a security perspective.
In a typical process, the integration of software functionality into a software application adheres to the following general approach. First, a risk analysis is performed to determine threats and a likelihood of realizing those threats based on a characterization of the adversary. Second, security requirements are documented for the system to counter selected threats. Third, appropriate software security mechanisms are selected to meet the requirements established at the second step and minimize the vulnerabilities to the threats. Fourth, the security mechanisms are integrated throughout the system under construction. Lastly, the system is tested and results are documented for stakeholders, such as security evaluators and accreditors. The described process may be repeated as the system, the information processed, and risks evolve over time. It should be appreciated that the described process can be difficult to realize with precision in the real world.
The present invention addresses the fourth step of integrating security mechanisms throughout the system. It is at this step where certain difficulties can occur. One problem is that developers may lack the expertise to integrate security mechanisms in a proper fashion. In addition, many types of security functionality permeate the various parts of a complex application, with different software application developers responsible for those different parts. As the various developers implement similar security code in different places throughout the system, classic “code scattering” and “code tangling” problems often result, thus complicating evolution and tracking of such security mechanisms (i.e., code). These problems are typical of functionality that cuts across systems. Code scattering refers to like functionality which is needed across a system. References to such functionality show up in numerous places, complicating the maintenance/evolution of such code. Code tangling refers to such functionality becoming necessarily mixed in with code whose main purpose is to accomplish some goal unrelated to security.
Another consequence of the difficulty of integrating security mechanisms into application code is demonstrating to a security evaluator that such integration clearly maps back to original security-related requirements derived from the risk analysis. It can be easy for developers to miss integration points entirely; this is especially true as new code is added to a system subsequent to the initial integration of security countermeasures. Furthermore, should the details of a security mechanism's invocation change, developers are forced to revisit all the different places in the system where such invocations occur, with the consequence that certain updates may be missed.
As one example, consider an access control check in a finance application implemented as a service-oriented architecture. One might have access control checks for a wide variety of actions within such a system, from viewing certain reports, to updating accounting entries, exporting data to other systems, and performing system maintenance procedures. Suppose, for example, that there are twenty services in the architecture, six operations/service which require an access control check, and two lines of code per access control check. The result is an additional 240 lines of code (LOC) in the system to ensure that access control checks are invoked where needed. Such code is replicated across 120 distinct places (code scattering) where the operations are implemented. Furthermore, the focus of each operation is not access control but some other goal, such as report generation, so authorization checking code is mixed in with application code (code tangling). Besides access control, other common security tasks may include, logging/time-stamping/auditing, authentication checks, “just-in-time” encryption and decryption, message authentication code and signature generation and verification, locking and unlocking of critical data structures, session time-out checks, and assertion checks. In any given application function, multiple of these security tasks may be present, further exacerbating code scattering and code tangling problems.
Using the above example but expanding the average number of security-related tasks to five per service operation, the total lines of security-related code that are scattered/tangled rises to 1,200 LOC. This calculation only accounts for top-level services and ignores similar code in underlying software layers and supporting class libraries.
The security functionality described above is just one example of what are known as “cross cutting concerns” (CCCs). CCCs represent functionality found throughout systems that are difficult to modularize using traditional programming languages, including object-oriented languages, resulting in the code scattering and tangling properties discussed above.